前一天我們把 Model 從 CPU 移到 QCS6490 的 NPU。

但做到這裡，我又遇到一個問題：

手上的 Model，到底要怎麼進 Qualcomm NPU？

因為不同 Framework 出來的 Model 格式不一樣。

TensorFlow → .pb
LiteRT     → .tflite
ONNX       → .onnx
PyTorch    → .ts

這些 Model 不是拿到 QCS6490 就可以直接跑。

中間還需要經過 Qualcomm Neural Processing SDK，再往下面接不同的 Backend。

1. Qualcomm SDK 在中間做什麼？

可以把它想成一個轉接層：

TensorFlow   .pb
LiteRT       .tflite
ONNX         .onnx
PyTorch      .ts
      │
      ▼
Qualcomm Neural Processing SDK
      │
      ├── Qualcomm AI Engine Direct API
      │
      ├── HTP / DSP
      │
      ├── GPU
      │
      └── CPU

所以我們真正要確認的，不只是：

「這個 Model 能不能跑？」

而是：

「這個 Model 最後到底跑在哪裡？」

2. 為什麼這件事情很重要？

例如我們希望：

Model
  ↓
Qualcomm SDK
  ↓
HTP
  ↓
NPU

但如果某些 Operator 不支援，或者轉換時出了問題，就可能變成：

Model
  ↓
Qualcomm SDK
  ↓
部分 HTP
  ↓
部分 CPU

Model 一樣有結果。

但效能可能完全不一樣。

所以在做 Qualcomm Model Integration 時，我會特別確認：

• Model Format
• Operator 是否支援
• Input / Output
• Datatype
• Quantization
• Backend
• 有沒有 CPU Fallback

3. 這也讓我重新理解「NPU 加速」

以前我會比較直覺地想：

Model → NPU → 跑得快

實際上比較像：

Model
  ↓
Model Conversion
  ↓
Qualcomm Runtime
  ↓
Backend
  ↓
HTP / GPU / CPU
  ↓
Application

所以 31 FPS 背後其實有很多東西。

不是單純「換成 NPU」而已。

4. 對 PM AI Engineering 來說，最重要的是問對問題

當 Engineer 告訴我：

「這個 Model Qualcomm 可以跑。」

我現在會繼續問：

跑在哪個 Backend？

如果答案是 HTP，再繼續確認：

是不是全部跑 HTP？有沒有 CPU fallback？

最後才回到 Product：

這個 Model 放到我們的 Edge Device 上，效能到底夠不夠？

這也是我在做 Edge AI 之後，越來越覺得 PM 需要懂一點底層的原因。

不用自己寫完所有 Driver，

但至少要知道：

Model → SDK → Backend → Hardware

中間哪一層出了問題，最後都可能變成 Product Issue。

下一天，我們就來看另一個更麻煩的問題：

Model 跑得很快，但為什麼整條 AI Pipeline 還是會慢？